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This Technical Bulletin supersedes the UP-8605.6 bulletin dated 
December, 1978. Please destroy copies of the previousty issued 
documente the “R14” ftag in the outside margin of a page indicates 
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Te INTRODUCTION 


& This document is intended to give an 4nsight into mult i-thread 
I*®S 90 as imptenmented in OS/3- It defines the mutt i-thread 
‘concept, and contains information relating to system control, 
fecord locks, file usage and ACTION program designe The 
intormation is intended primarity for those individuats within an 
organization who are responstbte for the itmptementation of a 
multi-thread IMS 90 system and the design of ACTION programs. 


It ts assumed that the reader has a knowledge of the fottowuing 
Sperry Univac publications: 


- IMS 90 Programmers Reference Manuat UP-8083 
- OS/3 IS 90 System Support funct tons, UP-8366 
- IMS 90 Applications User Guitte, UP~-8614 
OS/3 Technical Bulletin #6, 1 ‘September, 1979 
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OVERVIEW 


The OS/3 IMS 90 system is available in both a single thread and 
multi-thread version. Single-thread IMS 90 provides Low volume 
applications with low-memory serial message processing white 
multi-thread IMS 90 pravides the large votume application the 
same consistent services as single thread with concurrent 
transaction processing requiring a modest memory increase. 


The obvious reason predicating any consideration toward use of 
multi-thread IMS 90 is response time. for the new user, it may 
be the apprehension that single-thread IMS 90 wilt not be 
sufficient to meet the response time requirede for the 
single-thread IMS 90 user this migration is usually apparent in 
an increase in votume. As volume increases, the need for 
consistent response times becomes a major concern. 


With the decision to use multi-thread IMS 90, the user must be 
conscious of the affect the application may have on IMS 90 
performance. 


This paper is intended to assist the potential multi-thread IMS 
9C user in attaining favorable results through extended 
explanations of IMS 90 facilities. 
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MULTI-THREAD IMS 90 
WULTI-THREAD IMS 90 CONCEPT 


Multi thread I1fS 90 is, briefly, the processing of several user 
requests concurrently, as opposed to seriaily.e Multi thread IMS 
$C provides the capabtlity to process input messages while 
concurrently processing input/output requests for existing 
threads and communication output requests for terninating 
threads. 


Multi thread IMS 9C achieves its performance capabilities via 
four functions: 


- Multi tasking 


Overlap of 1/6 requests 


- Concurrent execution of user action programs 


Sticking power 


Additional performance improvements are obtained by employing 


methods that enable IMS 90 to optimize the available systen 
resources and share its own internal resources. 


‘ Multi thread IMS 90 is designed to maintain a smooth systes 


batance while processing Large volumes of input, and stitt 


saintain acceptable response times and provide increased system 
throughput. ; 


3etet Multi-tasking 


Multi-tasking provides multti-thread IMS 90 with the ability to 
concurrentty schedule transactions for incoming messages, process 


output messages for terminating actions/transactions and service 


outstanding 1/0 requests for existing threads Cactions). 


There are four subtasks which are always present in the 
multi-thread I@S 90 system. The primary (job step} subtask is 
used mainty for startup and shutdown. The secondary subtask, 
known as the INC task, Is utilized exclusively by the Internal 
Message Control CIMC) routines, the ICAM interface for IMS 90. 
The tertiary subtask, known as the Main Task, ts employed for the 
execution of mainline code of IMS 90: the scheduling and 
terminating of transactions as well as the execution of user 
action pragrams. One or more additional subtasks may be 


allocated, via the job card, to process 1/0 requests on behalf of 
@ user action programe 
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FIGURE 3-1: Multi-Thread IMS 90 Tasking Structure 
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3-122 Overlapping of I/0 Requests 


Because single-thread IMS 90 executes through a single TCB, ImS90 
is waited until the conpletion of each 1/0 requeste In 
multi-thread IMS 90, a subtask is simply atlocated from the 
avaitable poot, whenever an action (thread) requests an 1/0 
function be performed. After issuing the 1/0 order to data 
management, IMS 90 may continue to service other requests from 
the Main Task, the IMC Subtask or the other 1/0 Subtaskse Upon 
completion of the 1/0 function, the thread will be queued for 
subsequent execution by IMS 90. The number of subtasks specified 
on the job card predicates the number of 1/0 subtasks available 
during the online execution of IMS 90 Cice, a vatue of 5 atlows 
for 2 1/0 subtasks, 6 atlows for 3 1/0 subtasks etce) A value of 
6 ts usuatly sufficient. 


Concurrency of Action Program Execution 


Multi-thread IMS 9C allows for 2 or more threads to access the 
Same action program concurrentlye This feature not onty 
contributes to the efficiency of IMS 90 but also conserves 
resources which may be employed toward scheduling and execution 
of additional threads. Details of this feature will be described 
in Section 7. 


@ 3.164 Sticking Power 


OS/3 Technical Bulletin #6, 


Undoubtedly the most transparent feature of multi-thread IMS 90 
is sticking power which allows an action program (non-resident) 
to remain in main memory until that space is needed for 
subsequent processinge when an action terminates, the space the 
action program occupies is essentially de-allocated, but not 
re-used as tong as there is avatlable space in the storage pool 
to continue the processing of incoming transactions. If this 
action program is needed again,g it can be scheduled without being 
reloaded. 


However, if an action program which is in memory has no potentiat 
users, and the space it occupies in the storage poot becomes 
critical toward the scheduling of a new thread, the action 
program space wilil be returned to the storage poot and be 
available for the scheduling of the new thread. 


September, 1979 
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re THREAD DEFINITION, COMPONENTS AND CONTROL 





4el THREAD DEFINITION 
In multi-thread IMS 90, a thread, which for simplicity’s sake 
will be defined as a unit of work within the IMS 90 environment, 
consists cf the following attributes: 
1e ‘Thread Controt Btock (€THCB) 
Ze Terminal Control Table (CCT) 
3. Activation Record (CA/R) 


4. User Action Program 


Se File 1/06 Areas 


4e2 THREAD COMPONENTS 


A thread can be associated with every input message and is active 
only for the Length of the action for which it is assigned. 
Therefore, it is conceivable that severat threads may be 
atlocated and ceallocated during the span of a transaction. 


4e2el Thread Control Block (THCB) 





The THCB contains atl necessary information pertaining to an 
action. It contains pointers to alt areas of the activation 
record as weil as the action, programs and terminal control 
entries which are active on behalf of a thread. 


When a thread is created, it is tdentified as either routine or 
urgent tn prioritye 


Threads are ordered in a tinked List which are serviced on a 
round-robin basis. Each thread that is designated as ready 
receives controt when its turn comes and retains control untit it 
must wait on some facility. Subsequently, this action is marked 
as busy anc controt is passed to the next thread that is ready. 
If no action threads are marked as ready, control will be 
transferred to the initial thread routine to determine if a new 
thread can be created. 


4e2e2 Terminat Controt Tabte (TCT) 


Each terminal in the IMS 90 environment has a TCT. The ICT 
serves as a Link between the terminal and the thread which is 
active on its behalf as well as providing constant terminal 
status and accumulated message countse 
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&e2eS Activation Record (A/R) 


Each thread is allccated a corresponding activation record. Thts 
iss in essence, the users” area for any data manipulatione Areas 
within the activation record are attocated based on values 
supplied in the ACTION section of the configurator. The A/R is 
comprised of the Program Information Block (PIB), Input Message 
Area (IMA), Work Area (WA), Output Message Area (OMA) and the 


Continuity Data Area (COA). The areas provide the user with 


facilities for program status, reception of input messages, 
temporary work areas, output reply messages to the terminials and 
essentiaily a common data area for succeeding actions 
respectivety. An A/R is static for the Length of the action for 
which #t exists. 


Figure 4-1 graphicatly depicts the multi-thread IMS 90 A/R in 


main storage and parameter List at the time an action program is 
given control. 


ACTIVATION RECORD CA/RD Rebs ADDR. 


TL PROGRAM INFORMATION BLOCK (P1B)} A j 


opi a 
MOLTUIEV UMA MERGIRS Gee 
[wore AREA GAD 
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CPARAM LIST) 
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& FIGURE 4-1: Multi-thread IMS 90 Activation Record Layout 
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User Action Procrams 


Action programs are loaded upon request, *f not atready in 
memory, or are specified as permanently restdent at configuration 
tine. Non-resident action programs are toaded randosty within 
the IFS 90 matin storage pool. Resident action prégrams are 
loaded once at startup time and then permanently reside in the 
main storage poot inmediatety preceding the IMS 90 Input Staging 
Areae 


File 1/0 Areas 


File 1/0 areas are attocated for each ISAM/IRAN file an action 
wishes to access before the thread is scheduted. 1/0 sreas are 
allocated based upon information supptied. in the FILES parameter 
of the ACTION section of the IMS 90 configurator. I/0 sreas are 
shareable between threads, inpitying stapty thet §f an 1/70 area 
already exists when a thread is initialized, t with be shared 
with the existing thread. Dam Retative fites are not buffered; 
therefore, an 1/0 area is not atlocated when the thread its 
scheduted. 


THREAD CONTROL 


Most aft the resources employed by a thread sre unique and apart 
from cther active threads in the mixe Therefore, each thread 
must, in some way, be uniquely identifiabte from other act ive 
threads in the system. To achieve. this, IMS 90 utilizes the 
unique date and tise stamp which ICAM provides with each input 
message. If the incoming wessage indicates the initiation of a 


new transaction, the date and time stamp is placed in the. 


OS/ 


Terminat Controt Yabte (ICT) and? corresponding Thread Controt 
Block (THCB). This unique stamp remains throughout the tife of 
the transaction regardtess of the number of actions invotved or 
types of succession employed. Since IMS 90 manipulates the 
gate-tise stamp to guarantee uniqueness, the time stamp cannot be 
used as a valid time of day. However, as of Release 6.0, & valid 
date and time of Action Scheduted is made avatlabite in the P18. 


Subsequent to atlocation of the THC8 and fnsertion of the 
date-time stamp, the user AJR ts allocated and corresponding 
addresses are ptaced in the THCB, any required 1/0 areas are 
allocated and their corresponding addresses placed itn the File 
Corterct Tabte CFCTI)» the user attion program is loaded (if: not 
resident), the Program Controt Table £PCT) address ts ptaced tn 
the THCB, the user Input message ts edited into the IMA from the 
Input Staging Area and controt ts transterred to the user action 
program at its designated entry point address. 
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Figure 4-2 shous the sutti-thread IMS 90 memory Layout. 
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FIGURE 4-2: Multi-thread IMS 90 Remory Layout 
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Se LOCK FEATURE OF MULTI-THREAD IMS 90 





Set LOGICAL LOCKS 


The lock feature of muiti-thread IMS 90 is provided to reaintain 
the integrity of the users” data files during ontine execution. 
It is not the intent of this document to describe the Lock 
mechanism as this is done quite adequately in the IMS 90 
Programmer Reference Manual UP-8083 and UP-8614 (as of retease 
$e2)- Instead, a description of when Locks are tmposed as wetl 
as when they are reteased, is provided to enable users to detect, 
eliminate and avoid both bottlenecks and deadtocks which may 
occur in a multi-thread IMS 90 system. 


Either of two togicalt lock options, lock-for-update or 
lcck-for-transacticn, may be selected for a Dam Relative, ISAM or 
ITRA® files in the File section at configuration time. 


Se1-1 Lock-for-update 


For Dam Relative files, the lock-for-update option causes a lock 
te be impased for a logical record when the record is retrieved 
via the GETUP function or added to the file via the INSERT 
function. For ISAM files, the GETUP and INSERT functions will 
impose a Logical lock for the file being accessed. These locks 
prohibit access to the record (DAMR and IRAM) or file CISAM) by 
other transactions until this Lock ts released. It does not 
prohibit further access to the same record or file by the same 
transaction. These tocks are reteased when one of the following 
occurs within the transaction which imposed the Lock: 





1e For the GETUP, the record #s updated by means of a PUT or 
DELETE functitcne for an INSERT function, the lock is 
released upon successful return from Data Management. 


Ze The action in which the Lock was imposed or a subsequent 
action terminates with the TERMINATION-INDICATOR of the PIB 
set to “°N” (normal transaction termination) of “A” 
(voluntary, abnormal transaction termination) or “S” (same 
as “A” with a request for snap) or the transaction 
involuntarily, abnormally terminates. 


3. The Programs in which the lock was faposed or a subsequent 
Program terminates with the TERMINATION-INDICATOR set to “E” 
Cexternal successor) or “0° (delayed internal successor). 


The LOCK-ROLLBACK-INDICATOR cf the PIB ts not applicable for 
files which have had the lLock-for-update option specified since 


IMS 90, in this casey coes not perform online recovery for those 
files. 
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Sete2 Lock-for-transaction 


& The tock-for-transaction, with DAM Relative and IRAM files, 

es causes a lock to be imposed for a togicat record when the record 
is retrieved VIA the GETUP function or added to the file via the 
INSERT functione For ISAM files, the GETUP and INSERT witl 
impose a togical tock for the file as well as the record being 
accessed. These tocks prohibit access to the record or file by 
other transactions until this lock tis released. It does not 
prohibit further access by the same transaction. These locks are 
released when one cf the following occurs within the transaction 
which imposed the tock: 


1. The action in which the lock was tmposed or a subsequent 
action terminates with the TERMINATION-INDICATOR set to “N%, 
“A” or “S” ofr the transaction involuntarily, abnormattly 

terminates. 


Ze The action which terminates with the TERMINATION-INDICATOR 
set to efther “E” or “D” and the LOCK=-ROLLBACK-INDICATOR set 
to “H” with pending tocks outstanding. The logical fite 
tock imposed by the GETUP is released and a record Lock is 
imposed providing file access to concurrent threads. 


36 The action in which the lock was tmposed or a subsequent 
action terminates with the TERMINATION-INDICATOR set to “E” 
or “D” and the LOCK-ROLLBACK-INDICATOR set to “Re. In this 
case, only those locks that have been imposed via GETUP 
function requests, and for which no corresponding PUT oF 
DELETE functicn requests have been issued, are released. 


©@ 


4. The action in which the lock was imposed or a subsequent 
action terminates with the TERMINATION-INDICATOR set to 
eftther “N7, “Es of “BD” and the LOCK-ROLLBACK-INDICATOR set 
to “0° to cause a) the rotitback of atk updates performed by 
this transaction to the previous rollback point, b>) the 
release of all Locks active for this transaction, and ¢c) to 
cause a new rollback point to be established for this 
transactione 


Se The action in which the lock was imposed or a subsequent 
action terminates with the TERMINATION-ENDICATOR set to 
either “E” or “D” and the LOCK~ROLLBACK-INDICATOR set to “N” 
will cause IMS 30 to establish a new rotlback point for the 
transactione Subsequent requests for file rottback wilt be 
effective onty to the new rollback point. This assumes that 
other rottback points are not established Later in the 
transaction by subsequent actions. 


Finally, lLogicat file tocks imposed for ISAM files cannot be 
carried from action to’actione Any file Locks active at action 
termination wilt be released: 


@ 1. File and record locks will be released for pending updates 
7 if the LOCK-ROLLBACK-INDICATOR is set to “R”. 
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2- If a SETL was issued, an ESETL wilt be issued by IMS 90 if 
it is not done by the action program. @ 





5Se2 CONTROL AND RELEASE OF INTERNAL LocKs 
SedetT ACTION Program Controt 


The user action pregram may, at its own discretion, at action 
termination specify subsequent lock discipline via the 
LOCK-ROLLBACK-INDICATOR (CLRID of the PIBe tock discipline is 
available only for those files which have specified 
tock-for-transaction (LOCK=TR) in the FILE Section of the IMS 90 
Configurator. Using Lock-for-update (LOCK=UP) does not provide 
lock carryover across succeeding actions. The defautt vatue for 
the LRI ts “N%, which releases alt locks previously imposed by 
this action and establishes a new roliback point. 


The holding of tocks across actions requires the spect fication of 
either °R°” or “H” for the tRI at action termination. 


Specifying the value of “H” will cause IMS 90 to hold alt locks 
active for this action and any preceding actions within this ; 
transaction. The value “R”® in the LRI at action termination wit 
release any pending tocks active for this action as well as any 
pending Locks active for previous actions within this transaction 
which may have been heid over. <A pending Lock is defined as ane 

for which a GETUP was issued but the corresponding PUT or DELETE @ 
function was not issued. 


If during an action program execution the determination is made 
that any previous updates are. void due to current circumstances; 
these updates, for the existing action and any previous actions 
for which locks were held, may be rolled back, to the Last 
rettback point. Specification of “0° in the LRI at action 
termination witl ferce all updates performed by this transaction, 
or to the last established roilback point if one has been 
established since initialization of this transaction, to be 
rctled back to their initial status. Further, att tocks active 
for this transaction wilt be reteased and a new roliback point 
established for this transaction, providing the 
Terminattion-Indicator is not set to “N“.e AS previously stated, 
the rollback facility is available only for files which have 
lLock-for-transaction specified. 


Table 5-1 summarizes the function of each of the 
LOCK -ROLLBAC K-INDICATORS. 
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TABLE 5-1: LOCK-ROLLBACK-INDICATOR (LRI) Values - (LOCK=TR) 
| 


| & Oe ae ne ee ee a ee a ee FE ee OEE EE EE EE PORE A ES I EE EE SE AE SS ES EN SE A ES cm SY 


Pf eR | | 
VALUE | FUNCTION 
| ----- |----------------~------------- +--+ + - +--+ -- + - + ee 

1 R {Retease alt pending tockse Pending locks are i 
H fincompleted function requests Cicee GETUP uwlo i 
i lcorresponding PUT or DELETE function). 
§ eee an fone cw en aces enna se ab te gece i av a Sith aah a cues aban ei iviceendesen ees 

1 4 JHotd alt tockse. This inctudes pending and | 
I lcomplete function Locks. 
| ----- |-----------------------+------------------- ---- +--+ --- = +--+ 

1 WN) JRetease allt locks active to this point imposed by this 1 
{ Itransactione Establish a new roltiback point for this I 
i Itransaction. 


( 
j 
' 
’ 
' 
( 
' 
{ 
' 
' 
' 
' 
| 
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' 
t 
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' 
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{ 
' 
t 
i] 
{ 
' 
' 
' 
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' 
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' 
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' 
' 
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' 
' 
{ 
{ 
t 
' 
' 
' 
{ 
' 
' 
' 
' 
' 
' 
' 
' 
f 
{ 
! 
' 


1 O [Rollback all updates active by this transaction to the 

| flast rollback point. Establish a new rollback point for | 
{ ithis transaction. 

i 


5.202 IMS 90 Internal Control 


Whenever a lock is imposed by an action, the Lock will reflect 
the date and tiwe stamp of the thread which imposed the tock. 

S further, a bit-map in the ICT is updated to reflect the file for 
which the lock was imposed. Subsequent requests to retease locks 
or normal transaction termination, causes this bit map in the TCT 
to be scrutinized to determine which files CFCT“s) should be 
‘scanned in locating Locks hetd by this transaction. then 
scanning each files” tock List entries, the date-time stamp 
assigned to this transaction is used to identify and release any 
and all Locks which say exist for the transaction in the list 
being analyzed. 


Upon successful action/transaction termination and releasing of 
existing locks Cif not held across actions) the user’s output 
message is scheduled for delivery and atl allocated resources are 
released. If the action has indicated a successor, the terminal 
remains in interactive-mode and the next incoming sessage will 
not initiate a new transaction. 
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6. FILE USAGE WITH MUL TI-THREAD IMS 90 


Ge1 FILE SHARING 





AUt data files are shareable within the IPS 90 environaent thru 
File Management. ISA, IRAM, DAM Relative and SA™ fites are 
Shareabte among actions on a func tion-by-function basts. ISAM 
‘and IRAM fites may be altocated exclustvety to an action for a 
series of sequential fite operations. Files are subsequentty 
Gealiccated etther explicitly by the actt#on or taptlicitty at 
actfon termination. 


6e2 FILE LOCKS 


Tabtes 6-1 and 6-2 summarize when locks are imposed and reteased 
wta function cattse 


TABLE 6-172 LOCK-FOR-UPDATE 


FO 8 0 © SS BOS OS OS OS © © Or Oe 8 sO Oe OO BO HOS OOO OO Re SE & OR OE SOE Oe 








| 2 4  PRELEASEQRETRIEVEQWILL NOT RE-§ nO §. 
§ fFILE RECORDE FILE -? LOCKED ETRIEVE LOCK-? LoCcKs } 
i {LOCK LOCK Ff LOCK $f RECORD FED RECORD PIMPOSED | 
catutetatatatatatatatel, Wnietetel ttatatatete! beteeteteteted nimeteteteteted letetetetentemteaaieted tetera 
QSETL x C4) t f i] t a 
LESETL i t xc) t ' $ 
1GETUP wxC3)$ x2) ¢ ¢ t Xx ] t 
QINSERT 9uc3)g x02) 8x03) $ ‘ x ¢ ry 
FPUTSDELETE ff # xd2> x3) to ] L i 
GET CSEQNTLD i ' ’ x ! ! x i 
[EET CRANDOM) | t ? t | x t x | 
| Eee, AE Ae, SL SCNT Seen e ee SERES, RR RERMON 
TABLE 6-2: LOCKED-FOR-TRANSALTION 
t ' t . PRELEASEIREFRIEVESWILL NOT RE-} wo f 
{ fFILEQCRECORD? FILE -f LOCKED JT TRIEVE LOCK-? LOCKS | 
‘ {LOCKE LOCK ( LOCK ff RECORD FED RECORD PIMPOSED! 
Prem ee enn mene Pores Joe cena fone mens fe rren n= t------ meen ef -—-----f 
ISETL xcd>4 ' { ' ’ { 
fESETL t 5 xa? = sf ' § 8 
*GETUP exe3d9 x2) 4 | q x t i 
RINSERT xC3db xC2> xn) ' ‘ x { | 
SPUT/JDELETE ¢ § xd2)d @eC3>d t ] q ! 
IGEY CSEQNTL)E i ' t x ' t Xx é 
QGEV CRANDOMDG r} t ] q x t x t 
Do tee es Ve te Sea oe ee ee ek 
4. ISAM and IRAM tiles 
Ze Att fites. 
3e For ISAM onty. © 
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7. 


r 7.1 


ACTION PROGRAM CONSIDERATIONS 


ACTION PROGRAM DESIGN 


One of the prime factors predicating the overall performance and 
memory size of multi-thread IMS 90 is the initial design of the 
user action programs. It is imperative that the design of the 
user action programs receive the utmost attention in any system 
design. The action program should never be construed as an 
online batch-type jobe It ts in the better interests of response 
times and overatt availability of IMS 90 resources that action 
programs abstain from extensive sequentiat searches on ISAM or 
IRAM files or extensive updating of any one or group of files in 
a single action. 


There are relatively few rutes which should be considered when 
designing an efficient multi-thread IMS 90 action program. 
Severat of the following points reflect response time 
considerations; the remainder directly affect memory sizes which 


could determine whether or not an extra thread can be scheduled 
for execution. 
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Figures 7-1 and 7-2 depict the relationships between a 
Transactions Action and Program in the IMS $0 environment. 
Figure 7-1 indicates a simpte relationship where a single action 
program execution constitutes a transaction, action and programe 
Figure 7-2 shows a compound relationship where several action 
iterations make up the total transaction and in the finat 
sequence, multiple action program executions comprise the 
resulting action. 


INPUT MESSAGE j I j 

PROCESSING iprogramlAction {transaction 
OUTPUT MESSAGE | | 

NORMAL TERMINATION H } 


FIGURE 7-1: SIMPLE TRANSACTION /ACTION/PROGRAM RELATIONSHIP 


INPUT MESSAGE ] t i 

PROCESSING | t i 

EXTERNAL SUCCESSION [PROGRAM FACTION | 

(Locks hetd - No Roliback Point) i i 

t 

i 

INPUT MESSAGE ! j 

PROCESSING j ! | 

DELAYED INTERNAL SUCCESSION [PROGRAM FACTION | 

(No Locks held - Logicat { } i 

Rollback Point] i ! i 
[TRANSACTION 

j 

INPUT MESSAGE 1 { j 

PROCESSING i i i 

IMMEDIATE INTERNAL SUCCESS ION FPROGRAM | j 

(Locks hela - No Rottback Point)]} { i 

{ACTION | 

! i 

PROCESSING i j j 

NORMAL TERMINATION {PROGRAM | I 

CIMPLIED ROLLBACK POINT) { j 

. b 


FIGURE 7-22 COMPOUND TRANSACTION/ACTION/PROGRAM RELATIONSHIP 


Type of Action Program. 


The most efficient form of action programs in a multi-thread 
environment is the re-entrant (BAL) or shareable (COBOL). 
Re-entrant and shareable action programs can provide processing 
of severat concurrent threads. Seriatty reusable actions cannot 
provide this type of processing because they are self-modifying. 
when possible and when there is a choice of action program types 
te be used for an IMS 90 application, re-entrant or shared code 
should be used. In any case, care should be exercised in the 
design of an IMS 9C application to remove the potential of 
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deadtocks (see Section 8. Deadlock. 


Re-entrant and Shareabte action programs attow muttipte threads 
concurrent access. It, for exaspte, thread 1 has progras-A and 
thread 2 atso requests Program-A. Thread 2 wilt be queued untit 
pregras-A issues a function request to INS 90. At this tine 
thread 2 witt be given use of program-A. When thread 2 perfornas 
a tunction request to IMS 90, thread 4 wilt be re-scheduted for 
prograsg-A and so one 


ACTION Program Size 


Keep the size of action programs as minimat as posstbte. Never 
design an action program to do #t att. The targer the action 
progras, the fever number of concurrent threads that can be 
scheduted. The object of sulti=thread IMS 90 4s to service as 
many requests as possible, concurrently. Large action programs 
tend to not only occupy more sesory but atso hamper concurrent 
processing due to being either CPU bound or imposing extended 
tists of locks for records andésor files which are atso needed by 
other threads. These sttuations may atso tead to extended 
pertods of tnternat waiting for resources to become avaitabte. 


1/0 Requests 


Do as tew I/0°s as possible. A rute of thumb to fottow to 
provide performance and etiainatée extended tocking of fites and 
records, ts to timit action programs to seven 1/0"se Granted, 
this wilt not atways be the casé; but under no circumstances 
shoutd #t become the exception. tong sequentiat searches on 
indexed ftites (SETL/ESETL) shoutd be avotded at att costs. A 
tiait of 100-200 1/0°s should te the naximum for sequent tal 
search functtons. Extended sequential functions tock cut the 
file trom ath users and cause not only increased response times 
but atso deadtock situations. If sequential searches are a 


mecessitys random GET“s should be employed with the action 


prograa incrementing the key each time. This witt eltminate fite 
locking and permit access to att users. 


Number of Files Accessed 


Access as few files as possible. Before a thread can be 
scheduted, alt resources that wilt be needed for execution aust 
be secured. Thts inctudes 1/0 areas for each file. A tack of 
avattable resources wttt cause a thread to be queued and a 
smatter thread to be scheduledse If an 1/0 area needed tor a 
transaction being scheduted has been atlocated previously for an 
existing thread, this 1/0 area with be shared between the two 
threads. Sut this may not atways be the case. For exagple, if a 
thread to be scheduled needs four separate ISAM or IRAM files 
whose average btocksize 4s 2K bytes; an extra 8K bytes of 
overhead memory exists for this thread, if the fites requested 
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are not being used by currently active threads. 


7eteS Locks 


Impose Locks only when necessarye The majority of deadlocks that . 
occur in an established multi-thread IMS 90 environment originate 
from file locks, record locks and the use of seriatly-reuseable 
programs « 


If the user is performing simple interrogation of a file or a 
selected group of records within a file, the random GET function 
should be used instead of the GETUP or SETL sequencese The SETL 
function wilt impose file locks for ISAM and IRAM files. The 
GETUP function will impose file locks for ISAM and record tocks 
for IRAM and DAMR tiles. 


Providing for as many of the above points as possible when 
designing action programs wilt assist greatly in attaining and 
maintaining the desired through-put necessary for any 
agpplicatioan. , 
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8. DEADLOCKS 
| e «Bet «DEADLOCK DEFINITION 


| The deadtock situaton occurs when Multi-Thread IMS 90 detects an 
uncorrectable situation within the transaction mix which will 
indefinitely inhibit the processing of one or more threads due to 
conflict in availability of necessary resources. Deadlocks 
result from inconsistencies in user design of the overall 
application. whenever a transaction is in design phases, the 
user must also be cognizant of other transactions which may be 
active concurrently within the IMS 90 system mix. The design of 
@ transaction shoutd be done in such a way so as not to cause 
direct conflict with other transactions over available resources. 


82 DEADLOCK SITUATIONS 


The following sections are examples which provide explanations of 
feasible deadlock situations. 


Be2e1 Deadly Embrace - File Availability 


Thread 1 issues a GETUP (and imposes a lock) for FILE-A and a 

subsequent GETUP for FILE Be. Thread 2 which is executing 

concurrently with thread 1, issues a GETUP Cand imposes a tock) 
& on FILE-B and issues a subsequent GETUP to FILE-A.e 


This is more commonly referred to as a deadly-embracee Both 
threads will be waited indefinitely because Thread 1 holds the 
tock for FILE-A which Thread 2 is waiting tor, and Thread 1 witt 
be waited for FILE-B which thread 2 holds the tock for. The only 
resolution is for IFS 90 to cancel one or both threads and allow 


terminal cperators to reenter the transactions. 


In order to avoid this situation all action programs shoutd 
access all files in the same order and insure the PUT or DELETE 
is issued as soon as possible after the GETUP is performed. 


Be2e2 Deadly Embrace - Program Availability 


This situation can only occur with serfiatly-reuseable 
Cnon-shareabte) action programs. 


Thread 1 employs program-A which issues a GETUP (Cand imposes a 
tock) for FILE-X. Subsequently, a PUT is issued (record is stilt 
locked) and succession (regardless of type) is done to program-Be 
Program-A atso elects to carry the record Lock over to program—Be 
Thread 2 has meanwhtle been scheduled using program-8 which 
tissues a GETUP to FILE-X requesting the same record thread 1 is 


@ holding. 


This also is a deadly embrace. Thread 1 cannot continue because 


19 
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thread 2 has Program-B. Thread 2 has been queued because the 
record requested is tecked by thread 1. @ 
If program-B were shareable or reentrant, thread 2 would be 
queued for the record, and thread 1 would proceed through 
succession and execution of Program-He When the record tock is 
released, thread 2 would continue norsat processinge 


Beled Pending tocks 


when using Immediate Internal Succession the user should exercise 
great care not to teave pending Locks when terminating the action 
program. tock discipline is not interrogated during Immediate 
Internal Succession and pending tocks normatly taply file tocks 
(except for DAMR files}. If the user intends to perfors 
Iamediate Internal Succession an ESETL, PUT or Delete should be 
issued for each outstanding SETL and GETUP respectively before 
action program terminattone This witt eliminate any unnecessary 
waiting by other threads for the files being held by this action. 


8.2-4 Record Lock 


when a record is locked by a thread, regardless of filetype, all 
subsequent requests for access to that record will be queued. 


The most common occurence of this situation is when one or more @ 
transaction types update a controt record for a file. This 
should be avoided whenever possible. 


These are the common causes of deadlocks. Care should be taken 
to avoid these situations and thus eliminate any bottlenecks that 
wilt hamper processing. 





OS/3 Technical Bulletin #6, 20 September, 1979 
Rev. 1 





9. MULTI-THREAD IMS 90 MODULES and Generat Fiow 
@ 9.1 MULTI FHREAD IMS 9 MODULES 


The following sections give a brief description, by functional 
area, of each of the Multi thread IMS 90 modules. 
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%ete1 Functional Area - STARTUP 





The START-UP modules prepare IMS 90 for on-line execution. & 
MODULE REQUIRED 
NAME VSe OPTIONAL FUNCTIONS 
1 a 
ZEAS TART R te READS PARAM CARD 


Ze CALLS ZQHSTART 

3. ASSIGNS SECONDARY STORAGE KEY 

4e ATIACHES SUBTASKS 

Se ATTACHES MAIN SUBTASK STXIT 
‘CODE 

6. OPENS FILES 

7e ESTABLISHES STORAGE POOL 

Be LOADS RESIDENT ACTION PROGRAMS 

Ge CALLS ZB#LOAD TO LOAD ON-LINE 


PHASE 
2 
ZQHS TART R Te READS CONFIGURATION TABLES FROM 
NAME REC 
2e PERFORMS NECESSARY LINKAGE 
BETWEEN TABLES 
3. ALLOCATES INPUT MESSAGE 
STAGING BUFFER AREA & 
3 
2 CAMOP MT OR PERFORMS INTERNAL MESSAGE CONTROL 
ORIENTED START-UP PROCEDURES 
te LINK TO ICAM VIA MOPEN SVC 
Ze SEND “IMS READY” MESSAGE 
TO APPROPRIATE TERMINALS 
3- ATTACHES IMC SUBTASK, 
4e ACTIVATES STXIT AND OPCOM 
STXIT CODE IF OPCOM=YES 
3 
7 CHIOPEN R EXECUTES ACTUAL ICAM MOPEN 
2 
ZCHBICHA R PROCESSES // PARAM BA CARD 
3 . 
2 CWB IC HX. ° 0 PERFORMS BATCH ORIENTED 


INITIALIZATION PROCEDURES 


1 
FUNCTIONS 1 - 4 ARE EXECUTED UNDER JOB STEP TASK; 5 - & UNDER 
PAIN SUBTAS Ke @ 


2 
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EXECUTES UNDER J08 STEP TASK. 


3 
EXECUTES UNDER IMC SUBTASK. 
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Gete2 Functional Area - THREAD SCHEDULING 


The THREAD-SCHEDULING swodutes altocate and dealtocate action 
related resources and controt thread execution. 


REQUIRED 
vWSe OPTIONAL 


“MODULE 
NAME 


eo 


4 
Z1aTM R 1. 


10. 


& 
ZTHIMC R 


4 
ZEALOAD R 


4 
ZAHAS R 1e 
2e 
3e 


4e 
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FUNCTIONS 


SCHEDULES THREADS AND 1/0 FOR 
THREADS 
CREATES THREADS 

TERMINATES THREADS 

WAITS THREADS FOR INTERNAL 
FACILITY 

POSTS THREADS WHEN FACILITY 
AVAILABLE 

REQUESTS 1/0 SUBTASK FOR THREAD 
POSTS THREADS WHEN I/0 COMPLETE 
CONTAINS INTERRUPT TIMER STXIT 
CODE 

CONTAINS PROGRAM CHECK START 
CQDE 

CONTAINS ABTERM STXIT CODE 


AWAKES IMC SUBTASK FOR OUTPUT PROC & 


LOADS IMS 90 PHASES 


ALLOCATES MAIN STORAGE 
RESOURCES FOR ACTION VIA 
ZS#MSM 

CALLS ZCHRDMT TO BUILD IMA 
CALLS ZJ#SCHED TO READ DDR AND 
DETERMINE DRA SIZE 

CREATES THREAD FOR ACTION 

VIA ZTHTM | 

CALLS ZAHLOADR TO LOAD PROGRAM 
CALLS ZFHGENZ TO READ CONDATA 
SETS UP SECONDARY STORAGE 
PROTECTION FOR USER 
DEALLOCATES MAIN STORAGE 
RESOURCES FOR TERMINATING 
ACTION 

CALLS ZFHGEN2 TO WRITE CONDATA 
CALLS ZFHGEN2 TO PERFORM FILE 
MANAGEMENT TERMINATION 
PROCEDURES 

REQUESTS OUTPUT PROCESSING 





September, 1979 


4 


Z SHR SM R ALLOCATES AND DEALLOCATES 
(CONDITIONALLY OR UNCONDITIONALLY)D 
BLOCKS OF STORAGE FROM THE MAIN 
STORAGE POOL 


5 
ZAAL OADR R LOADS USER ACTION PROGRAMS 
ZO#TOnnn R 4- CONTAINS THOSE TABLES REQUIRING 
ASSEMBLY GENERATION 
where: 
nnn=CONFID Ae IMS 90 AND USERR DATA FILE 
OF NETWORK DTFS 
SECTION IN Be ICAM-IMS 90 SHARED TABLES 
CONFIGURATOR 
2e CONTAINS PREALLOCATED 170 
AREAS FOR AUDFILE AND NAMEREC 
6 
Z €#M THSO R Fe SENDS ERROR MESSAGES TO CONSOLE 
2e PRINTS SNAP FOR ABNORMALLY 
TERMINATED ACTIONS 
4 


EXECUTES UNDER MAIN SUBTASKe 


5 : 
EXECUTES UNDER CONTROL OF AN 1/0 


6 


SUBTASK. 


EXECUTES UNDER CONTROL OF MAIN SUBTASK AND 1/0 SUBTASK. 
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Functional Area - INTERNAL MESSAGE CONTROL CIMC) 





The IMC modules control the communications environment Cic€ey Aa . 
terminal input and output). 
MODULE REQUIRED 
RAPE VSe OPTIONAL FUNCTIONS 
3 : 
ZCHRIMCMT R Te DIRECTS PROCESSING OF INTERNAL 
PESSAGE CONTROL CIMC) MODULES 
Ze CONTAINS ALL ENTRY POINTS FROM 
ICAM AND DETERMINES SUCCESSIVE 
PROCESSING 
3e CONTAINS INTERFACE WITH 
APPLICATION MANAGEMENT FOR 
OUTPUT PROCESSING 
3 
ZCAHIIP RT R Te QUEUES INPUT MESSAGE. FOR 


APPLICATION MANAGEMENT 

2e PROCESSES REGULAR TERMINAL 
COMMANDS 

3e ALLOCATES AND DEALLOCATES 
BUFFERS FROM THE INPUT MESSAGE 
STAGING AREA FOR INPUT AND 
OUTPUT MESSAGES 


@ 


ZCHFKYMT 0 PROCESS FUNCTION KEYS 

ZCHMICHKT R PROCESSES MASTER TERMINAL COMMANDS 
q 

ZCHOPCOM 0 ALLOWS SEVERAL MASTER TERMINAL 


COMMANDS TO BE ENTERED FROM CONSOLE 


ZCHICODE R SENDS AUTOMATIC STATUS MESSAGES 10 
APPROPRIATE TERMINALS UNDER CONTROL 
OF THE IMC INTERRUPT TIMER STXIT 
CODE 


4 

ZCH#RDMT R DETERMINES SIZE OF IMA AND MOVES 
USER-DESTIRED INPUT MESSAGE INTO 
IMA. PERFORMS NO EDITING, GENERAL 
EDITING AND/OR LOWER CASE 
TRANSLATION AS SPECIFIED IN ACTION 
SECTION 


& 
ZCHEDMT 0 PERFORMS EXPANDED INPUT PROCESSING 
. ON INPUT BASED ON EDIT RECORD 
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CREATED BY OFFLINE EDIT TABLE 
GENERATOR (ZHHEDT) 


3% : 
ZO#QUTMT R Te CONTROLS OUTPUT MESSAGE PRO- 
CESSING AT ACTION TERMINATION 
Ze CONTROLS OUTPUT MESSAGE PRO- 
CESSING DURING ACTION VIA 
SEND COMMAND BY DIRECTING 
USE OF UNSOLICITED OUT- 
PUT MODULE (ZO#UNSMT) 
3 
ZOAUNSAT 0 1. PROCESSES CONTINUED RESPONSES 
TO ORIGINATING TERMINAL 
Ze PROCESSES SWITCHED OUTPUT 
C1eEe, OUTPUT TO OTHER THAN 
ORIGINATING TERMINAL) 
3e CONTROLS USE OF UNSOLICITED 
OUTPUT INDICATOR 
3 
ZO#CONAT 0 Te VERIFIES AUXILIARY OEVICE 
SPECIFICATION IN USER OUTPUT 
MESS AGE 
Ze CONTROLS CONTINUOUS OUTPUT BY 
HANDLING DELIVERY NOTIFICATION 
3e CONTROLS OUTPUT-FOR-INPUT 
ZI#TAB R SERVES AS TRANSLATE FABLE FROM 
LOWER CASE TO UPPER CASE 
ZCHU4ET 0 PROCESSES DOWN-LINE LOAD 


REQUESTS TG A UTS400 TERMINAL. 


7 


EXECUTES UNDER CONTROL OF OPERATOR COMMUNICATIONS ISLAND CODE. 
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Gelee Functional Area - BATCH PROCESSING 











The BATCH PROCESSING modules controt the processing of batch & 
transactions through IMS 90. 
MODULE REQUIRED 
RAME VS. OPTIONAL FUNCTIONS 
3 a ‘ 
ZCHICAM R DECODES ICAM SVC REQUESTS FROM 
OTHER IMC MODULES 
3 
ZCAZZB TH 0 PROCESSES ZZBTH MASTER TERMINAL. 
COMMAND 
3 
ZC #B TC HC © DIRECTS THE PROCESSING OF BATCH 
FUNCTIONS 
3 
ZCHBTHMT . 0 PERFORMS MULTI-THREAD DEPENDENT 
OPERATIONS 
ZCHBPR Te 0 CONTAINS A PRINTER OTF 
3 
ZCHBPRT oO CONTAINS A PRINTER DTF 
3 
Z CHB PRTS 0 CONTAINS A PRINTER DTF 
3 
ZCHBPRT4 0 CONTAINS A PRINTER OTF 
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9-1-5 Functional Area - FILE MANAGEMENT 


FILE MANAGEMENT modules control the access to ath IMS 90 and user 
data files. 


RODULE REQUIRED 
NAME VS. OPTIONAL FUNCTIONS 
4 
Z FAGEN2 R 1. INTERCEPTS ALL REQUESTS FROF 
ACTION PROGRAMS AND FROF IMS 90 
MODULES TO ACCESS/UPDATE FILES 
2e VALIDATES PARAMETER , 
3e SELECTS AND GIVES CONTROL TO 
THE APPROPRIATE. MODULE TO 
EFFECT THE REQUEST 
&4e MANAGES RECORD LOCKS 
Se PERFORMS FILE MANAGEMENT RE- 
LATED TERMINATION PROCEDURES 
AT ACTION END INCLUDING RE- 
COVERY PROCEDURES AT ABNORMAL 
TERMINATION 
6 : 
Z FAS IRI R : Fe PROCESSES REQUESTS FOR ACCESS 
TO THE NAMED. RECORD FILE 
CIeEws GET, GETC) 
_@e MAINTAINS A MAIN STORAGE 
SUBFILE OF THE MOST RECENTLY 
ACCESSED RECORD 
6 
ZFRES IAMS Rr. PROCESSES REQUESTS FOR ACCESS TO 
THE CONDATA FILE CIeE«sy GET, PUT) 
6 
Z FHAUDIT 0 PROCESSES REQUESTS TO AUDIT FILE 
CleEes GET, PUT) 
6 
Z FAISAM R PROCESSES THE FOLLOWING RANDOM AND 
SEQUENTIAL REQUESTS TO ISAM USER 
DATA FILES 
4- GET 
Ze GETUP 
3e. PUT 
4&-e DELETE 
Se INSERT 
6. SETL 
Ze ESETL 
6 
Z FRED AMR 0 PROCESSES THE FOLLOWING REQUESTS TO 
DAM RELATIVE ORGANIZATION 
(RELATIVE RECORD) USER DATA FILES 
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1. GET 
ge GETUP 
3. PUT 
4. DELETE 
Se INSERT 





6 
ZFHSEQ 6 PROCESSES PUT REQUESTS TO SEQUEN- ’ 
TIAL USER DATA FILES 


6 
Z FATRACE 0 WRITES BEFORE AND AFTER IMAGES TO 
A JOURNAL TAPE FOR OFFLINE RECOVERY 


Z FASEPRM 0 USER SUBPROGRAM INTERFACE 


6 
Z FA TOR? 0 WRITES OUTPUT MESSAGE TO 
TOMFILE WHENEVER A ROLLBACK 
POINT IS ESTABLISHED. 


4 
Z GASNAPM 0 EDITS SNAP OUTPUT 


6 
ZFHO PC2 0 PROCESS OPEN/CLOSE OF 
FILES IN RESPONSE TO Z2Z20PN/ZZCLS e 





6 
ZFRIRAM 0 PROCESS THE FOLLOWING RANDOM 
AND SEQUENTIAL REQUESTS TO 
IRAM USER DATA FILES. 
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9.126 Functional Area - DEFINED RECORD MANAGEMENT 


DEFINED RECORD MANAGEMENT controls ait requests toa user defined 


files. 
MODULE REQUIRED 
NAME ¥VS- OPTIONAL 
4 
Z JHSCHED R 
4 
2 SHD RM? 0 
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FUNCTIONS 


REQUESTS THE RETRIEVAL OF THE 
APPROPRIATE DATA DEFINITION RECORD 
AND DETERMINES THE SIZE OF THE 
DEFINED RECORD AREA REQUIRED FOR 
THIS DEFINED FILE 


INTERPRETS AND DIRECTS FUNCTION 
CALLS FROM UNIQUE AND USER ACTION 
PROGRAMS WHICH INVOLVE A DEFINED 
FILE. DEFINED RECORD MANAGEMENT 
SUPPORTS RANDOM RETRIEVAL, 
SEQUENTIAL RETRIEVAL, AND RANDOM 
UPDATE OF DEFINED FILES FROM ONE 
OR MORE LOGICAL FILES 
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9.1.7 


0S/3 





Functional Area - SHUTDOWN 


SHUTDOWN performs those functions 


MODULE REQUIRED 
NAME wSe OPTIONAL 
Z T#S HD WN R 1. 
de 
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necessary to terminate IMS 90. 





FUNCTIONS ’ 


oee seen ww 


WRITES RESTART RECORDS 
NAME REC 
CLOSES ALL FILES 


TO : 
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9.22 MULTITHREAD IMS 90 GENERAL FLOW 


Figures 9-1, 9-2 and 9-3 are provided to summarize the generals 


internat procesing flow thru several of the functional areas of 
multi thread 18S 90. 
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9-2-1 input Message 


Figure 9-1 shows the generat processing for an input message from © 
receipt by IMS 90 to the scheduling and Loading of an ACTION 


Programe 
ore eee ne 2) i aaa 

H caf mMme | --------- J i 

[LICAM | -->[SUBTASKI ->|THREAD MGMT | , 
conn ~------ (3)] | ------------- { 

1 ~>JACTION SCHED. |} 

j ->] ; j<- 
aclatatetatetenetaie TEE Cotetetetetetetetetenetened | 
\TERMINALS (4)] | GEN. REG. | 

\ / {f | PROC-- H 
aaa TEE Sotetehahetetatetetetetetes | (5) 


->|MAIN STORAGE | 
| MANAGEMENT | 


! 
| ACTION] t 
[PROGRAM] t 

t 


ce ee es ee 


see enews we ewoe 


1. ICAM notifies Internal Message Control of an tnput message. 


Ze Internal Message Controt performs editing of the tnput 
messages, queues the action and awakes the main taske 





36 Thread Management schedules Action Scheduling to allocate 
resources to process the input. 


4. Action Scheduling gives Main Storage Management Control to 
allocate space for Control Blocks, Action Program and the 
Activation Record. 


Sa Once this has been done, Action Scheduling Loads the Action 
Program and moves the input message into the users Input 
Message Area CIMA). 


FIGURE 9-3: GEWERAL FLOW - INPUT MESSAGE 
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G9e2ee GET Request 





Figure 9-2 is provided to show the internat processing of an 
& ACTION program GET request for a record in a user data fite. 
MAIN TASK 
7 { THREAD MGMT { 
 F ateaeteeatieheteaeneria { 1/0. 
. . 1 ACTION SCHED J} SUBTASK 
|o--- 2-9 ------ {| «)  eeaieneetesteteseaned 
>| GEN REQ PROC J------>] FILE | 
i i |) <------ [MANAGEMENT] 
4) | feroe crete f (4) Foo ULL 
i oUMAIN STORAGE | T 
if | MANAGEMENT t 1 ¢3) 
| |-------------- ! v 
§ ob ACTION I Sea emanne 
->| PROGRAM { 1 DATA i 
, SE ee REET t [MANAGEMENT] 


1. User Action Program requests a record to be retrieved from a 
user data file. 


2e General Request Processor gives control to the appropriate 
File Management module. 


Ze File Kanagement awakes an I/0 subtask which issues the 
& request for the record from Data Management. 


&. The record is returned to the Action through File Management 
and General Request Processore 


FIGURE 9-2: GENERAL FLOW - GET REQUEST 
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e3 Termination Processing 


The general processing flow for termination from an ACTION 
program is shown in Figure 9-3. 


--------- wnnennnnn--- (EB) eae ---+----- 


I 1 «> | [<----- | f 
1 ICA [<----[ IMC SUBTASK j----- >|THREAD MGMT [<- 
Oe ee | es ©. >. a | t $2) 
C63) feenenn------- | 
j ->| j-- 
v ~- ACTION SCHED ]<- 
1 bee----- coon t J 
sohahatachaheteaetietes | 4 . t 1 
\TERMINALS (7)] (GEN REG PROC | | 
\ / bo Jenne n-------- } «1 
ee ee —>IMAIN STORAGE | | 
| MANAGEMENT j | 
osteaieiestesetetemeatered -! 4 
i ACTION ' ot 
| PROGRAM j-- 





1. User Action Program terminates itself and Action Scheduling 
ceatlocates the resources for this action. 


Ze Action scheduling then initiates output message processinge 
3. Thread Management issues a CAWAKE to the IMC task. @ 


4. The IMC subtask takes the output message and issues an 
MWRITE to ICAM. 


5 Once the output message is passed to ICAM, the Internat 
Message Control Task awakes the main task. 


Ge Thread Management notifies Action Scheduling to complete 
termination processing. 


7. Action Scheduling gives control to Main Storage Management 
to release the areas assigned to the Activation record, 
Control Blocks, and Action Program. 


FIGURE 9-3: GENERAL FLOW - TERMINATION PROCESSING 
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